Flugzeug-Vogel-Kollisions-Schaden

Teamrollen & Problemstellung

Rollen im Team

• Projektleiterin: Yvonne Gisser
• R-Experte: Roland Bauer
• Machine-Learning-Experte: Dusan Resavac

Problemstellung

~ Vorhersage, ob die Kollision eines Flugzeugs mit Vögeln zu einem Schade führt ~

Art der Ausführung: Klassifikation

Ziele & Datengrundlage

Zielsetzung

• Zur Evaluierung der finalen Ergebnisse werden sowohl der Recall als auch die Precision herangezogen.

• für mehr Informationen siehe: Modell 4/4 - Metrik

Referenzdatensatz

~ FAA wildlife strike reporting program ~

• Daten: wildlife.faa.gov
• Spezielles an den Daten: unausgewogen

Beschreibung des Datensatzes

Modell 1/4

Auswahl der Zielvariable

• Überlegung: Wir möchten den Schweregrad hervorsagen
  • Lösung: Wir wählen die Variable “DAMAGE_LEVEL” als abhängige Variable / Zielvariable
    • alle anderen Variablen mit “DAM_” beginnend werden weggelassen

Modell 2/4

Beschreibung der Zielvariable

# A tibble: 6 × 2
  DAMAGE_LEVEL  count
  <chr>         <int>
1 D                81
2 M              8550
3 M?             6638
4 N            162666
5 S              4211
6 <NA>          97227

Modell 3/4

Auswahl der Prädiktoren

• Annahme: Wir nehmen an, dass es einige Variablen gibt, die einen Einfluss auf unsere abhängige Variable haben, darunter jene mit “STR_” beginnend
  • Lösung: diese Variablen werden als unabhängige Variablen / Prädiktoren ausgewählt

Modell 4/4

Metrik

• Recall für Klasse “D” (destroyed) soll mind. > 0.9 sein
• Rest soll als Klasse “S” (substantial) klassifiziert werden

Wichtig:
1. Grobe Schäden dürfen nicht unerkannt bleiben
2. Die False Positive Rate darf nicht zu groß sein
=> da dies in unnötigem Wartungs- bzw. Reparatur-Aufwand resultieren würde

Weitere Modelle

• Basismodell: häufigste Klasse von “DAMAGE_LEVEL”
  => N
  
• Statisches Modell: ?
• Dynamisches Modell: ?
  
  Diese Modelle machen für unseren Use Case keinen Sinn!

Projektorganisation

• regelmäßige Team-Meetings:
  finden online auf Microsoft Teams statt
  
• Dokumentation
  (inkl. Aufgabenteilung, Workflow & Meilensteinplan):
  liegt auf dem GitHub Repository des Projekts
• Verwaltung der Aufgaben:
  findet am Kanban Board des Projekts statt
  

Aufgabenteilung 1/2

• Die Aufgaben werden so aufgeteilt, dass jede*r in jedem Bereich des Projekts mitwirkt. Die Rollenverteilung dient dementsprechend lediglich der Information, bei welcher Person sich bei Bedarf für den jeweiligen Bereich am schnellsten Hilfe geholt werden kann. Das Ziel besteht also darin, dass sich nach Abschluss des Projekts jedes Teammitglied in allen Projektbereichen selbstsicher fühlt.

• Dabei wird darauf geachtet, dass für jedes Mitglied ungefähr der gleiche Arbeitsaufwand besteht - um die Fairness zu gewährleisten.

Aufgabenteilung 2/2

beispielhafter Projektablauf: Wir übernehmen seine Kategorisierung der Aufgaben

Plan für die Ausarbeitung 1/2

Pipeline / Workflow

Plan für die Ausarbeitung 2/2

Zeitplan / Meilensteinplan

Backlog TBD

Beantwortung von Fragen

• Frage unsererseits:
  Wie sollen wir die NAs unserer Zielvariable behandeln?
  
  • Optionen:
    1) NAs entfernen
    2) NAs Labels zuordnen => Overkill?